EKS マネージドノードグループ
翻訳の具合によって「管理ノードグループ」と表記されることがある。
（セルフマネージドの方は「自己管理」と表記されていることがある）
コンソールからシュシュっとワーカーノードを作れて嬉しそう。
IAM Roleは事前に作っておかなくてはならない。セルフマネージドノードとの間で使い回すな、とコンソールに注意書きがある。リンク先に詳細説明がある。
クラスター内の他のマネージドノードグループで使用されていないワーカーノード IAM ロールを使用するマネージドノードグループを削除すると、そのロールは aws-auth ConfigMap から削除されます。クラスター内のいずれかのセルフマネージドノードグループが同じワーカーノード IAM ロールを使用している場合、セルフマネージドノードは NotReady ステータスに移行し、クラスター操作は中断されます。
他のマネージドノードグループで使用されている場合には、削除を思いとどまってくれるが、セルフマネージドの方は確認してくれない、ということらしい。
マネジメントコンソールで作成
初めて使う場合はIAMロールを用意する必要がある。
セルフマネージドノードを作るときに使ったCloudFormationテンプレートから、ロールを作成する部分だけ抜くことにする。
code:yaml
AWSTemplateFormatVersion: "2010-09-09"
Description: Amazon EKS - IAM Role for managed nodegroup
Mappings:
ServicePrincipals:
aws-cn:
ec2: ec2.amazonaws.com.cn
aws:
ec2: ec2.amazonaws.com
Resources:
NodeInstanceRole:
Type: "AWS::IAM::Role"
Properties:
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service:
Action:
- "sts:AssumeRole"
ManagedPolicyArns:
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AmazonEKSWorkerNodePolicy"
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AmazonEKS_CNI_Policy"
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
Path: /
Outputs:
NodeInstanceRole:
Description: The node instance role
Value: !GetAtt NodeInstanceRole.Arn
ロールさえ用意しておけば、EKSのコンソール内だけで完結して、本当にシュシュっと作れる。
EKSマネジメントコンソールから作った場合は、CloudFormationスタックは（少なくとも見える形では）残らない。
作成時に、Kubernetesラベルを指定できるが、ここで指定せずに、あとでkubectlを使って付けることもできる。ただし、あとでkubectlで付けた場合、EKSマネジメントコンソールには表示されない。
作成時に付けたラベルをkubectlで後から消せるのか、消した場合コンソールの表示はどうなるのかは不明（たぶん、消すことはできて、コンソールは更新されない気がする）。
eksctlで作成
eksctlから作った場合は、CloudFormationのスタックが残る。IAMロールとマネージドノードグループを作っている。「マネージドノードグループというリソース」を作っているのであって、EC2インスタンスを直接は作らない。
v0.26.0以降は、起動テンプレートも作成するようになった。
マネージドノードグループの交換
設定ファイルに書いている場合
managedNodeGroupsに新しいグループ書き足す
eksctl create nodegroup -f cluster.yaml --exclude=[古いの] --include=[新しいの]
eksctl delete nodegroup -f cluster.yaml --include=[古いの]
または
eksctl delete nodegroup --cluster cluster-name --name [古いの]
古いグループをYAMLから削除
AWS CLIで作成
code:shell
aws eks create-nodegroup \
--cluster-name $CLUSTER_NAME \
--nodegroup-name $NODEGROUP_NAME \
--scaling-config minSize=1,maxSize=4,desiredSize=3 \
--subnets $SUBNET_ID1 $SUBNET_ID2 $SUBNET_ID3 \
--ami-type AL2_x86_64 \
--node-role $IAM_ROLE_ARN \
--labels $KEY=$VALUE \
--launch-template name=$LAUNCH_TEMPLATE_NAME,version=$LAUNCH_TEMPLATE_VERSION
https://gyazo.com/619360842fc5994147b6b04d3308bc5b
ドキュメントにはこう書いているが、起動テンプレート名とIDの両方を入力するとエラーになる。※2.0.58
/icons/hr.icon
マネージドノードグループは、EKS APIにいくつかの新しい概念を導入します。
https://gyazo.com/d546888130e5a8eb53f28b1429336c95
マネージドノードグループ以前は、EKS APIは、複数のアベイラビリティーゾーン（AZ）にまたがる高可用性コントロールプレーンを提供し、ロギングとポッドレベルの最小特権アクセス（IAM）サポートを含んでいました。 コントロールプレーンを作成したら、eksctl、CloudFormation、またはその他のツールを使用して、クラスターのEC2インスタンスを作成および管理します。
つまり、EKSのAPIにワーカーノードの管理機能がなかった。それが、
EKS APIが拡張され、右側に示すように、Kubernetesデータプレーンをネイティブに管理できるようになりました。EKS管理コンソールでノードグループを一級市民にしました。これにより、クラスターを実行するために使用されるインフラストラクチャを一箇所で管理および視覚化することが容易になります。
AWSは、マネージドノードグループ（MNG）を使用するときに、underlying(?)インスタンスを保護および維持する責任も負います。 ただし、Fargateとは異なり、MNGはインフラストラクチャ/クラスターを自動的にスケーリングしません。 これは、クラスターオートスケーラーまたは他のテクノロジー（ネイティブAWS自動スケーリング、SpotInstのOcean、アトラシアンのEscalatorなど）で処理できます。 https://gyazo.com/c6ce4cfe1a7b648828fccdb171dd50fd